Upcoming versions of PostgreSQL will be phasing out the MD5 hashing method within the authentication infrastructure of the database, as first suggested by Nathan Bossart in 2024. In doing so, PostgreSQL will become a safer and more secure database for everyone. Its architecture will be more resilient to brute-force attacks, more computationally expensive to deal with, and more suitable for secure authentication.

In this article, Lukas Vileikis details everything you need to know – including what this all means for your application, your database, and your users.

In late 2024, a message by Nathan Bossart hit the database spotlight. Within it, he proposed a “multi-year, incremental approach to remove MD5 password support from PostgreSQL.”

Before we dive in completely, let’s establish one important thing first: what exactly is MD5?

What is MD5 authentication for passwords?

Put simply: it’s a hashing mechanism that was used widely to hash passwords in the past. Hashing is the process of transforming data into a hash value, or, in other words, a string of characters, using a hash function (sort of a formula in math.)

Hashes are a one-way function, meaning that it’s impossible to “reverse” a hash function (and to know what the hashed value was.) As such, hashing is used for digital fingerprinting and integrity validation – and there’s also password hashing.

There are multiple functions incorporating password hashing, all of which are outside the scope of this blog. However, to summarize, these are functions like Blowfish and BCrypt, and others like PBKDF2 – which we’ll explore a bit more later.

MD5 used to be a popular choice, but technology evolved and MD5 didn’t. So, it’s now considered outdated and insecure.

What about PostgreSQL’s support for MD5 authentication?

A decade or so ago, when computing power was far smaller than it is now, MD5 was considered an ‘okay’ hashing mechanism. As such, many databases – NoSQL and SQL-based platforms alike – quickly implemented MD5 into their architecture. It was simple to implement, came with little overhead, and found other suitable use cases as well.

However, as time went on, even news sources like The Register started picking up on issues with MD5 relating to databases like PostgreSQL.

MD5 was farewelled from PostgreSQL’s authentication mechanism back in 2017, switching to a version of SHA-256 instead. PostgreSQL took this approach because doing so fixed several weaknesses in how passwords were stored.

With this version of SHA-256, passwords were ‘salted’ (a random value would be appended to hashed values making massive values of hashes harder to crack for an attacker). Hashing would be intentionally slower. And, finally, computations on such a hashing algorithm would be far more expensive than on default MD5.

PostgreSQL removing MD5: how it came to be

First, it’s important to note that PostgreSQL’s developers have only started taking the steps to effectively suspend support for MD5 hashing going forward. So, for now, MD5 is still supported – but with caveats:

Here’s a graph to make everything simpler to understand:

The point here is simple: MD5 is being sunsetted, and the phaseout has begun.

Today’s ‘better’ options: SCRAM, MD5, and PBKDF2

I’ve already explained what MD5 is, and touched upon other hashing mechanisms like Blowfish and BCrypt. I also mentioned PBKDF2 as another alternative – but what exactly is it?

PBKDF2 (Password-based Key Derivation Function 2) is a function used to turn a value (usually a password) into a secure hash designed to resist brute-force attacks.

PBKDF2 works by repeatedly performing hashing an ungodly number of times (sometimes even millions) and, by doing so, significantly increases the effort required for a password to be cracked. It’s widely used in extremely security-sensitive applications, such as password managers and authentication systems.

Some password managers like 1Password even have entire threads explaining how they use PBKDF2 to secure your most valuable assets. Most valuable assets are the likes of credit cards and passwords.

Understanding PBKDF2 is crucial for understanding how PostgreSQL approaches password hashing in the present day. I mentioned earlier that PostgreSQL switched from MD5 to SCRAM-SHA-256. Well, SCRAM-SHA-256 includes PBKDF2 by default.

Here’s what that means:

SCRAM-SHA-256 implements PBKDF2 by default – while other hashing algorithms do not. This may well be the main reason it’s been chosen over MD5 as the default method for hashing in PostgreSQL.

So, PostgreSQL is implementing SCRAM-SHA-256. What does that mean for you?

PostgreSQL implementing SCRAM-SHA-256 into its infrastructure means that, upon login, it will now peruse SCRAM verifiers rather than MD5 hashes.

In effect, functions that authenticate users in PostgreSQL will now look similar to this one:

Verifier = PBKDF2SHA256(password, salt, iterations)

Deriving a verifier in this way improves password security in PostgreSQL because:

In simpler terms – the verifier is derived by performing these four steps:

While these steps improve security, there are two downsides to consider:

SCRAM-SHA-256 and PBKDF2 in PostgreSQL: other points to consider

PostgreSQL scrapping MD5 in favor of SCRAM-SHA-256 and PBKDF2 affects the authentication infrastructure of your database – but not necessarily the passwords your application stores for its own users.

Put simply, using a different hashing mechanism affects the users inside of PostgreSQL: their roles, database authentication, and the credentials you use to connect to the database itself. However, it does not affect the passwords you store when your users register to use your application.

This means that when you build (or even ‘vibe code’) your application, you can register users while hashing their passwords. Just use any safe hashing method (e.g. BCrypt or Blowfish), and store them with or without a ‘salt’ – that’s up to you.

This update does not affect the ability to store passwords belonging to the users of your application.

In summary

If you desire, I propose you read how this issue was approached by the engineers at EDB itself – their comments can be found here, here, here, and here. You will see them mentioning that removing support for MD5 in full isn’t going to be pretty as there’s a lot of baked-in things still around in PostgreSQL.

In general, though, Nathan’s initial idea of dropping support for MD5 was received very well. It remains to be seen how long this ‘sunsetting’ process will take, but we’re definitely stepping in the right direction.